Currently, there are two beta releases available: WebObjects Beta 2 for Window NT platforms and WebObjects Beta 1 for Solaris and NEXTSTEP platforms. Webobjects Beta 2 will be made available for Solaris and NEXTSTEP platforms in the very near future.
Tested Configurations | On NT Workstation or Server | On UNIX platforms |
---|---|---|
Netscape + CGI adaptor | works fine (but see 64029) | works fine |
Netscape + NSAPI adaptor | works fine (but see 65583) | works fine |
IIS Server + CGI adaptor | works fine (but install as in 65135) | N/A |
WebSite | does not work | N/A |
Purveyor | not tested with Beta 2 | N/A |
NCSA, CERN, Apache + CGI | N/A | works fine |
Summary: On NT, Microsoft IIS Server requires a special installation of WebObjects (65135).
Description: Microsoft IIS Server currently does not work properly on NT Workstation. On NT Server, if you install WebObjects under a C:/NeXT directory, the cgi adaptor won't autostart your applications correctly. The IIS Server creates subprocesses with a special user that has no privilege at all, and that has no access to the NEXT_ROOT environment variable. An autostarted application won't have any privilege either, and won't be able to locate NeXT resources (for example TimeZone files).
Workaround:
First:Also, if you're using the IIS, the URL to your WebObjects application should contain /Scripts/WebObjects.exe instead of /cgi-bin/WebObjects, as the cgi-bin directory is actually called Scripts. For example, http://server/Scripts/WebObjects.exe/Examples/HelloWorld is the right way to invoke the HelloWorld application.After installation:
- Install all your NeXT software under the root directory. When the installer asks you for a directory name to be the root of all NeXT software, set it to the root directory of a drive (such as C:\).
- When asked for your cgi-bin directory, you should enter the path of the Scripts directory.
Then, either:
- In the Scripts directory rename WebObjects to WebObjects.exe
- In C:\NextLibrary\WebObjects\Executables, copy DefaultApp to DefaultApp.exe
Or:
- Go to your WWW Server configuration panel and change the anonymous user to another user with administrator privileges. This will allow you to autostart web applications from the browser.
- Start your web applications by hand.
Summary: Incompatible C:\temp or /tmp file between WebObjects Beta1 and WebObjects Beta2. (63809)
Description: The format of the file C:\temp\WebObjects.conf on NT (or /tmp/WebObjects.conf on UNIX platforms) changed between Beta1 and this release. The new release won't be able to read an old file left over from a previous release installation.
Workaround: - On NT, make sure you delete all WebObjects.* files from the C:/temp directory before running your new release.
- On UNIX platforms, delete all WebObjects.* files from the /tmp directory or just reboot after installing and the /tmp directory will be cleaned.
Summary: Load balancing doesn't work with certain HTTP servers running on NT and Web Applications on Unix (64029)
Description: This concerns you if your server follows the CGI protocol but passes the CGI environment variable PATH_INFO with backslashes '\' instead of forward slashes '/' in the path. On the browser side, the error message is just "Did not receive any response from application." The Web Application logs : "Raised in returning response to client."
Workaround: Currently there is no workaround.
Summary: WebObjects may crash on NT while trying to autostart compiled examples (65284)
Description: If you are logging the adaptor activity to C:/temp/CGIMessenger.log (which means you have a C:/temp/logWebObjects file), when autostarting a compiled web application you won't get any response back in the browser. This comes from a bug in a logging call in the adaptor.
Workaround: There are two solutions:
- Just reload the first page. As the application has already been started, the first page will now load properly.
- Switch off the adaptor logs by removing the C:/temp/logWebObjects file.
Summary: Autostart for compiled examples in /NextLibrary/WebObjects/Executables does not seem to work (65377)
Description: The path to your binary under WebObjects/Executables must be the same as the path under WebObjects in your document root. For example, your binary is called HelloWorldObjC. If you have your executable in /NextLibrary/WebObjects/Executables/HelloWorldObjC, and your URL is http://fqdn.com/cgi-bin/WebObjects/Examples/HelloWorldObjC, then it won't work. However, if your executable is in /NextLibrary/WebObjects/Executables/Examples/HelloWorldObjC then the above URL will work.
Workaround: Either by copying or linking , create the same path to your binary under /NextLibrary/WebObjects/Executables as you have under DocumentRoot/WebObjects.
Summary: On NT with the Netscape server, NSAPI adaptor doesn't load-balance properly (65583)
Description: This comes from the fact that the Netscape Server on NT is multithreaded and not multi-processed.
Workaround: There are two different workarounds:
- Use the cgi-adaptor with Netscape on NT.
- Or fix the NSAPI adaptor source and recompile on NT by replacing line 117 of WOServerAdaptor.c with:
#ifdef NeXT_DOLE srandom(getpid()+(int)GetCurrentThreadId()) #else srandom(getpid()); #endif
Summary: Windows NT: Software group name with parenthesis crashes installer (64008)
Description: During installation the installer will ask you to specify a name for the software group on NT. Parenthesis in the name will crash the installer.
Workaround: Use the default group (as suggested by the installer). If you need to specify another group name, use alphanumeric characters only.
Summary: Windows NT: Netscape HTTP servers on NT do not accept cgi programs with an '.exe' extension. (64034)
Description: For the CGI server adaptor to work with the Netscape servers, the CGI adaptor (that is, the WebObjects program in the server cgi-bin directory) can't have any extension. Other NT HTTP servers may require the '.exe' extension.
Workaround: Add the '.exe' extension to the WebObjects program if your NT HTTP server requires it.
Summary: Hyperlinks in forms will not invoke their action methods (64012)
Description: If a WOHyperlink has an action attribute and is located within a form, the action will not be invoked.
Workaround: WOHyperlink's with action attributes must reside outside of forms.
Summary: Application subpath from WebObjects to application name cannot exceed 64 characters. (63809)
Description: Applications are identified by their "extended name", that is the path from <document_root>/WebObjects to the application name (e.g.Examples/HelloWorld in /NextLibrary/WebServer/htdocs/WebObjects/Examples/HelloWorld). This identifier string should not exceed 64 characters.
Workaround: Make sure that the application extended name does not exceed the 64 characters limit.
Summary: Windows NT: [WOApp pathForResource:@"Database/DodgeData" ofType:@"dict"] fails. (63818)
Description: On NT, resources cannot be located in nested directories.
Workaround: Resources should be kept right underneath the application directory (for example, in the DodgeLite example the database dictionary is kept in <document_root>/WebObjects/Examples/DodgeLite/DodgeData.dict instead of <document_root>/WebObjects/Examples/DodgeLite/Database/DodgeData.dict).
Summary: NSMutableArray arrayWithContentsOfFile: does not work (63927)
Description: [NSMutableArray arrayWithContentsOfFile:@"aFileName"] does not work.
Workaround: Use [NSMutableArray arrayWithArray:[NSArray arrayWithContentsOfFile:@"aFileName"]];
Summary: Automatic set methods don't work when a variable is capitalized (64001)
Description: WebScript has some problems using the automatic 'set' method to set variables which begin with a capitalized letter.
Workaround: Start your variable name with a lowercase letter. If you have to use a variable name that starts with a capital letter, implement the 'set' accessor methods yourself (For example, if your variable is named MyVar implement the setMyVar: method).
Summary: On Windows NT, DefaultApp can't be run from the DOS shell (63978)
Description: NT expects executables to have the '.exe' extension when they are executed from the DOS shell.
Workaround: Copy DefaultApp to DefaultApp.exe before you execute it in a DOS shell.
Summary: WOBrowser {value=...} has inconsistent behavior. (63926)
Description: When using the value attribute in WOBrowser, under some circumstances the WOBrowser may not work properly (for example, the selection may be lost). This is especially true when the value is mapping multiple attributes of the browser items (see Buy Page, method descriptionForSailboard in the CyberWind example).
Workaround: Try to change the value to something different.
Summary: Parsing error in while, for, and if statements that contain a single while, for, and if that is not inclosed in curly braces. (63818)
Description: The following statement will raise and exception:if (x) while (!x) y=1;
Workaround: Use curly braces (that is, if (x) { while (!x) y=1; })
Summary: WebScript does not respect numerical operation priorities for statements of the form ( (x+y) == z ). (63597)
Description: A statement in the form: if ( ((x + 4 *3) + 5 * 6) == y) needs to be rewritten as: if ( ((x + 4 *3) + (5 * 6)) == y).
Workaround: Use balanced parentheses in conditions that involve numerical operations.
Summary: Comments in the HTML template within optionally terminated elements confuses the HTML parser. (63774)
Description: Having comments in optionally terminated elements such as <LI> will corrupt the HTML parser.
Workaround: Do not use comments in optionally terminated HTML elements.
Summary: Windows NT: Back slashes don't work in Bourne Shell with DefaultApp's -d option on Windows NT. (64007)
Description: This statement would not work in Bourne shell:DefaultApp -n 1 -p 3000 -d c:\\netscape\\ns-home\\docs Examples/HelloWorldCommand line parsing for NT expects forward slashes.
Workaround: Use forward slashes when in Bourne shell on NT.
Summary: Applications won't autostart (65795)
Description: WebObjects application can be autostarted only if the HTTP server is running as a user with administrator privileges.
Workaround: One workaround is to reconfigure the server to run with administrator permissions. Another is to launch the application from the shell..
Summary: Trailing slash in application name launches DefaultApp (63973-fixed)
Description: If you type http://localhost/cgi-bin/WebObjects/Examples/HelloWorld/ instead of http://localhost/cgi-bin/WebObjects/Examples/HelloWorld, a DefaultApp is started and you'll experience an error during subsequent transactions. This default application should be killed and the URL typed again without the trailing slash at the end.
Workaround: Do not start applications with the trailing slash.
Summary: The WebObjects CGI server adaptor will crash when inadvertently launched from the command line. (63779-fixed)
Description: The WebObjects program in the server cgi-bin directory should never be launched manually from the command line or by double clicking on it. This program is launched by the HTTP server when a request is received. When launched manually, the WebObjects cgi adaptor will generate a bus error.
Workaround: Do not manually launch the WebObjects server adaptor.
Summary: Arguments such as ?a=b&c=d are lost in URL (63876-fixed)
Description: "GET" type arguments in a URL are not passed to the WOF application.
Workaround: Do not specify the FORM method (in the HTML template or in the WOForm declaration), the default is always a POST method.
Summary: Windows NT: WebObjects doesn't work with servers that require an '.exe' extension for the CGI program. (64886-fixed)
Description: Such is the case for the O'Rielly and Purveyor servers where URLs need to be in the form http://host/cgi-bin/WebObjects.exe/Examples/HelloWorld. To WebObjects, the extension looks like an erroneous version specifier, which confuses the URL parser.
Workaround: None. This problem will be fixed in the next release.
Summary: Interaction problems with Microsoft's Internet Information Server. (65359-fixed)
Description: The beta version of Microsoft's Internet Information Server (IIS) has interaction problems with WebObjects Beta 1.
Workaround: Currently there is no workaround. We are working closely with Microsoft, and a beta release fixing the problem will be provided in the near future.